Serve the 2026-07-28 protocol revision from the conformance fixture and gate it in CI

Motivation and Context

The conformance suite can already exercise the 2026-07-28 draft revision — draft scenarios
run over the stateless per-request lifecycle, the runner tells client fixtures the resolved
version via MCP_CONFORMANCE_PROTOCOL_VERSION, and --spec-version can force the
carried-forward scenarios onto the new revision — but our fixture only spoke the 2025
stateful lifecycle and our legs never passed --spec-version, so the serving stack now on
v2-2026-07-28 had no referee. This wires the fixture to the new entry point, adds
spec-version-forced legs, and gates everything in CI as a three-way split:

• 2025 legs (constant, gated): test:conformance:server (active) and
  test:conformance:client:all keep the shared baseline (expected-failures.yaml) and stay
  green with no regressions.
• 2026 draft suite: test:conformance:server:draft exercises the draft-only scenarios
  against the new serving path; its remaining failures live in the shared baseline and burn
  down as the SDK gaps close.
• 2026 carried-forward legs (new): test:conformance:server:2026 and
  test:conformance:client:2026 run --suite all --spec-version 2026-07-28 so the
  carried-forward scenarios are also exercised at the new revision. Both are gated against
  one new shared baseline (expected-failures.2026-07-28.yaml, client:/server: sections
  like the existing file) because the name-keyed shared baseline cannot express
  version-split outcomes.

This also bumps the pinned @modelcontextprotocol/conformance release from 0.2.0-alpha.3 to
0.2.0-alpha.4: its mock servers now include resultType in results, which the SDK's
2026-07-28 client decode requires, so the carried-forward client scenarios can complete at
the new revision.

What changed

• everythingServer.ts: requests claiming the per-request _meta envelope (including
  server/discover and malformed claims) are served through createMcpHandler, backed by
  the same fixture server definition; everything else stays on the existing stateful session
  path unchanged.
• everythingClient.ts: reads MCP_CONFORMANCE_PROTOCOL_VERSION; tools_call speaks the
  2026 lifecycle on 2026-07-28 runs (version negotiation + per-request _meta); new
  request-metadata handler driven by versionNegotiation: { mode: 'auto' }.
• New scripts test:conformance:server:2026 and test:conformance:client:2026
  (--suite all --spec-version 2026-07-28), plus one new step in each of the two jobs in
  .github/workflows/conformance.yml to run them.
• New baseline expected-failures.2026-07-28.yaml shared by the two new legs, every entry
  with a reason comment, grouped by what unblocks it (15 server entries, 25 client entries).
• expected-failures.yaml: request-metadata, caching,
  http-custom-header-server-validation, and server-stateless now pass and are removed;
  the header and the remaining entries' comments are updated to the current pin and the
  settled -32001/-32602 rejection codes.
• @modelcontextprotocol/conformance pin 0.2.0-alpha.3 → 0.2.0-alpha.4 (lockfile change
  scoped to that package).
• One client test name updated to stop describing the -32001 assignment as pending an
  upstream decision (assertions unchanged).

How Has This Been Tested?

• Against the 0.2.0-alpha.4 pin, all legs exit 0 with zero stale baseline entries:
  test:conformance:server 42/0 (unchanged), test:conformance:server:draft 6→39 passed
  checks (14 expected-failure scenarios remain), test:conformance:client:all 317→324 passed
  checks (15 remain), and the new legs test:conformance:server:2026 63 passed / 18 failed
  checks and test:conformance:client:2026 207 passed / 36 failed checks, with every failure
  covered by the new baseline.
• The new legs gate the same way as the existing ones: stale baseline entries and unexpected
  failures each make the leg exit non-zero (observed directly while burning down the
  baseline entries that started passing).
• pnpm -r typecheck, lint:all, docs:check, and the client package test suite pass;
  pnpm install --frozen-lockfile succeeds against the updated lockfile.

Breaking Changes

None — test fixture, CI wiring, baselines, and a dev-dependency pin bump in a private
package.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Remaining expected-failure groups, by what unblocks them:

• Multi-round-trip requests (SEP-2322): the input-required-result-* family (server, in both
  the draft suite and the 2026 carried-forward leg) and sep-2322-client-request-state.
• SEP-2243 header enforcement in the SDK: the remaining http-header-validation reject cells
  (missing Mcp-Method/Mcp-Name headers and the Mcp-Name cross-check) and the client
  header scenarios.
• SEP-2164 error semantics, the client auth scenarios (SEP-2468 / SEP-2352 / SEP-990), and
  SEP-2106 $ref handling: same entries as before, mirrored into the 2026 client section
  where those scenarios also run.
• SEP-837 application_type during DCR plus the 2026 lifecycle in the fixture's auth flow:
  the auth entries that only fail on the forced-2026 client leg.
• json-schema-2020-12 (server 2026 leg only): pre-existing fixture/baseline issue that
  fails identically at 2025 in --suite all; not a 2026-path regression.

http-custom-header-server-validation passes with all checks skipped (the fixture has no
custom-header-annotated tool yet); the SEP-2243 reject cells remain covered by the
http-header-validation entry.